IP Multimedia Subsystem (IMS) is a 3rd Generation Partnership Project (3GPP) standardised network architecture that provides an access network independent standardised interface for creating services, charging mechanisms and better Quality of Service (QoS) than best effort. Examples of the services that are implemented on IMS at the moment are PSTN functionality, Push-to-talk over cellular (PoC), Presence, Instant messaging and video sharing.
A Converged IP Messaging (CPM) workgroup inside the Open Mobile Alliance, OMA, aims to remove the silos between traditional messaging services caused by technical differences, and provide users with a smooth, unified service experience. The objective of OMA CPM is to consolidate common functionalities of existing messaging services and new features introduced by the convergence of communications brought by session initiation protocol (SIP) based technologies. These aims are defined in the document “Converged IP Messaging Requirements, Candidate Version 1.0”, 6 Nov. 2007 (OMA-RD-CPM-V1_0-20071106-C).
It will be possible for third-party applications to use these capabilities, and these third-party applications also can interact with CPM users as participants. The CPM will also provide the functionality to enable CPM based service users to communicate seamlessly with the users of non-CPM communication services which allow to transport real time media (e.g. audio, video) or discrete media (e.g. text messages) between two or more users, such as Short Message Service (SMS), Multimedia Messaging Service (MMS), email, IMPS (Instant Messaging and Presence Service), Simple/IM (SIP for Instant Messaging and Presence Leveraging Extensions/Instant Messaging), Voice over IP calls, PoC (Push-to-talk over Cellular).
One of the most important and key features in the CPM service deployment is interworking with legacy systems. One of the main problems in interworking is how a recipient responds to a message received via an interworking function (IWF), i.e. a gateway between the CPM environment and the non-CPM environment. When there is interworking between non-CPM environment and CPM environment, the interworking function will sometimes get an address/identity from the non-CPM environment that might not be valid in CPM environment and needs to be resolved for the CPM. For successful interworking, the interworking function might resolve the non-CPM addresses by some other means or allocate temporal CPM addresses for the non-CPM addresses and maintain a table for mapping the temporal CPM addresses with their corresponding or associated non-CPM addresses. The recipient client has to communicate with the sender by sending responses to the interworking function.
Session Initiation Protocol (SIP) is an IETF (Internet Engineering Task Force) application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. Some approaches have been proposed for improving the flexibility in routing of the SIP messages. In IETF Request for Comments RFC 4458, the Request-URI (Uniform Resource Identifier) is composed of the SIP Uniform Resource Identifier (URI) containing the voice mail URI and “target” parameter containing the URI of the mailbox as shown below:
INVITEsip:voicemail@example.com;\target=sip:+15555551002%40example.com; user=phone;\ cause=486 SIP/2.0In other words, RFC4458 puts two URIs into one Request-URI: a combination of the voice mail URI and the mailbox URI. This allows a sender to target the voice mail of the recipient instead of the recipient himself. Thus, the semantics relates to targeting a message to a particular entity of the terminating end point by a sending node.
In RFC 3841, a sender can set up his/her preference in an INVITE request sent to a recipient, i.e. sip:user@example.com, in the accept-contact header as follows:
Accept-Contact: *;actor=“msg-taker”;audio
The recipient has already registered his/her several contacts and capabilities preference. So when the server receives the INVITE request from the sender, the server does the matching with the preferences. If the matching was successful, then the request is routed accordingly to the appropriate entity of the recipient, i.e. to a voicemail box in this particular example. Thus, RFC 4458 and RFC 3841 propose different mechanisms for solving the same object, i.e. re-routing or routing to a specific entity of the recipient.